T-엔보이 실습 with solo.io
개요
엔보이를 공부하면서, 문서를 보고 따라하려다가 가랑이 찢어지겠다 싶었다.
문서의 양이.. 엄청 광대하더라..
그래서 Istio 1기 - Istio Hands-on 스터디에서 도전과제로 추천을 받은 것들 중에 조금 찾아보다 적당한 양의 실습을 할 수 있는 사이트를 따라가면서 실습을 하기로 마음 먹었다.
솔로 아카데미에서는 간단하게 실습을 하고, 시험을 쳐서 배운 내용을 잘 흡수했는지 테스트할 수 있다.[1]
실습에 활용된 모든 코드를 일일히 여기에 정리하려고 했는데, 생각해보니 그럴 필요가 없겠다 싶어서 중간부터는 그냥 체크할 만한 포인트만 정리하는 식으로 진행했다.
엔보이 기본
엄.. 초반에 동영상이 나오는데 이거 시간을 꼼짝없이 기다려야 하네..
기본적으로 이 실습은 도커 컴포즈를 이용해 엔보이를 띄우고 여기에 각종 설정을 넣는 식으로 진행된다.
업스트림 서버 역할을 할 코드는 이렇게 생겼는데, 그냥 어떤 경로를 받고 헤더에 unreliabe이란 게 있으면 20퍼센트 확률로 성공한다.
docker-compose up -d --build
간단하게 서버를 띄운다.
참고로 엔보이는 1.20버전이다.
실행되는 서비스는 총 5개로, 모니터링도 가능한 실습을 제공한다.
어드민 인터페이스
초기 엔보이 관리 설정 정보는 여기에 담겨있다.
19000포트로 접속할 수 있게 돼있는데,
실습에서는 이렇게 위에 탭으로 바로 접속할 수 있게 세팅을 해둬서 간단하게 확인할 수 있다.
리스너
git checkout lab1-2
다음 브랜치로 넘어가면 리스너 관련 설정이 추가된 것을 확인할 수 있다.
static resources 필드는 초기 설정을 의미한다.
여기에 리스너가 하나 세팅돼있는데, 8000포트의 트래픽을 받도록 돼있다.
리스너 필터는 트래픽 메타데이터를 통해 필터링을 진행할 수 있다.
필터는 체인을 걸 수 있는데, 특정 필터에서 트래픽에 대한 일련의 결정을 내린다면 체인은 끊기게 된다.
iptables랑 비슷한 방식이라 생각하면 되겠다.
ui에 리스너 칸에 들어가면 현재 열린 리스너를 확인할 수 있다.
위 설정에서는 typed_config라 하여 엔보이에서 지정한 여러 설정 타입 중 하나를 바로 사용하는 방식의 설정이다.
길게 써져있지만, v3 버전에서 직접 응답을 하는 설정이 담겨 있으며, 결과적으로 hello world가 출력될 것이다.
docker-compose restart envoy
curl --http0.9 host:8000
http0.9로 했을 때 성공적으로 응답이 온다.
클러스터
git checkout lab1-3
이번에는 리스너 필터 규칙에 tcp proxy를 세팅했다.
업스트림이란 이름의 클러스터로 모든 접두사까지 패스스루하도록 설정돼있다.
클러스터 필드를 보면 위에서본 업스트림이란 이름의 클러스터가 있다.
라운드로빈 로드 밸런싱을 수행하며, STRICT_DNS는 일반적인 dns 조회 방식으로 업스트림 호스트를 찾는다.
처음 보면 조금 의아할 부분이 load_assignment 필드 하위에 클러스터 이름을 또 지정하는 것이다.
이건 엔보이의 api 특성 상 세부적인 영역 별로 api 설정이 가능하도록 설계됐기에, 정적 파일로 세팅할 땐 중복되어 보이지만 이런 식으로 세팅하는 것이 일반적이다.
이제 다시 요청을 보내면 업스트림 서버가 응답한다.
클러스터 메트릭도 확인할 수 있다.
curl -s http://localhost:19000/clusters | grep upstream
터미널로 보고 싶다면 이렇게.
http 커넥션 매니저
라우팅
앞선 실습에서는 tcp 프록시로서 활용했지만, 엔보이는 더 대단한 놈이다!
http 요청에 대한 관리를 위해 엔보이는 HCM(HTTP Connection Manager) 필터를 사용한다.
이 필터에는 라우팅 설정이 들어간다.
가령 요청의 호스트를 보고 라우팅 경로를 설정하는 식이다.
git checkout lab2-1
이번엔 필터 부분이 상당히 길어졌다.
일단 이 필터의 타입은 http 커넥션에 대한 것인데, 맨 아래 필드를 보면 라우터 역할을 하게 될 것을 알 수 있다.
가상 도메인이 "hello.envoyproxy.io"로 들어온다면, 엔드포인트가 prefix를 포함할 때 업스트림 클러스터로 라우팅하도록 설정됐다.
요로코롬 오면 성공.
프로메테우스 메트릭이 노출되고 있는 것이 보인다.
재시도 설정
git checkout lab2-2
curl http://localhost:8000/hello -H "host: hello.envoyproxy.io" -H "unreliable: true" -i
이번에는 에러가 나는 트래픽을 재시도하게 만들어본다.
재시도 정책 필드가 생겼다.
docker-compose logs -f upstream
이제 다시 보면 한번 요청에도 알아서 재시도를 해서 성공 요청을 응답하는 것을 볼 수 있다.
메트릭을 보면, 두 번 요청해서 성공하는 동안 16번의 재시도가 있었단 것을 알 수 있다!
보안 설정
tls
이번에는 8443 포트로 리스너 설정을 했고, tcp 소켓 필드가 보인다.
여기에 tls 설정을 넣은 것을 볼 수 있다.
require_client_certificates
가 있으니 이 통신은 mtls 여야만 한다.
curl https://localhost:8443/hello -H "host: hello.envoyproxy.io"
그냥 통신을 하려고 하면 당연히 문제가 생긴다.
일단 서버의 인증서가 자체 서명 인증서기에 이를 무시하는 인자를 넣어야 한다.
이건 예상 못했는데, 클라 인증서 없이 성공했다.
공식문서에서도 위 설정은 클라이언트 인증서를 요구하는데 말이다..
curl에 뭐가 설정돼있나..?
ExtAuthz
엔보이 단에서 인증, 인가 로직을 수행하게 하는 것이 가능하다.
http 필터 필드에는 외부 인증을 요구하는 설정이 들어가 있다.
auth라는 클러스터로 트래픽을 보내는 것으로 세팅됐다.
아래 클러스터 필드를 보면 auth 클러스터 세팅이 된 것을 볼 수 있다.
curl https://localhost:8443/hello -k -H "host: hello.envoyproxy.io" -H "Authorization: bad-key" -i
이 상태에서 인증이 되지 않을 토큰을 넣어서 전달하면 당연히 403 에러가 나오게 된다.
curl -s http://localhost:19000/stats | grep 'ext_authz\|listener.0.0.0.0_8443.http.ingress_http.downstream_rq\|listener.0.0.0.0_8443.downstream_cx'
성공시키고 메트릭을 보면, 클러스터 단위로 인증 성공 여부와 리스너 설정 쪽에서의 성공 여부가 같이 표시되는 것이 보인다.
관측가능성
엔보이의 텔레메트리는 총 세 가지 정도로 분류할 수 있다.
- 다운스트림
- 들어오는 커넥션, 요청에 대한 통계를 볼 수 있다.
- 리스너와 프록시 필터 등의 정보도 여기에 담긴다.
- 업스트림
- 나가는 트래픽, 커넥션 풀, 라우팅 등의 정보가 담긴다.
- 서버
- 엔보이 자체가 수행하고 있는 기능, 메트릭에 대한 정보가 담긴다.
실습 대시보드에서는 쿼리를 어떻게 짰는지는 볼 수가 없는 모양이다.
로깅 설정은 이런 식으로 넣어주면 표준출력으로 나오게 된다.
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
위와 같은 포맷으로 로그가 남는다고 한다.
디버깅
이번에는 에러 상황을 만들고 체크하는 방법을 알아본다.
for i in {1..5};do curl https://localhost:8443/hello -k -H "host: hello.envoyproxy.io" -H "Authorization: workshop"; done
요청을 보냈을 때 no healthy upstream
이 출력되는 상황이다.
503에러가 뜬 것을 볼 수 있으며, 이전과 달리 가장 마지막 출력에 있어야할 업스트림 호스트의 주소가 보이지 않는다.
UH가 있는 부분은 응답 플래그를 답는 부분으로, UH는 NoHealthyUpstream을 나타낸다.[2]
어떻게 해야 저걸 줄여서 UH가 나오는 거임? 애너그램임?
클러스터에 건강한 상태의 호스트가 없어서 503을 내는 케이스이다.
실제 디버깅을 할 때 http 응답 플래그는 매우 유용한 정보를 담고 있기 때문에 이 부분을 먼저 보는 것이 상당히 도움된다.
문제 풀기
문제는.. 보통은 굳이 정리 안 하겠는데 틀린 문제만 정리한다.
딱 이 문제 볼 때 내가 아직 개념이 부족한가 느꼈는데, 역시나 틀렸다.
커넥션 매니저가 라우팅 규칙을 적용한 이후 바로 요청이 호출되는 서비스는 무엇인가?
정답은 Upstream이라고 한다.
나는 설정할 때 클러스터 이름으로 명시하기에 클러스터를 말하는 것이라 생각했는데..
아직 조금 더 개념 감을 잡을 필요가 있겠다.
후기
정말 튜토리얼 느낌으로 하기에 괜찮은 실습 사이트라고 생각이 든다.
사실 엔보이를 처음 공부할 때 조금 난감하게 느껴졌던 게, 다른 기술을 배울 때처럼 개념적으로 모르는 것은 없었다는 것.
항상 개념을 먼저 빡시게 숙지하고 본격적으로 설정법을 파고들어가다보니 개념 부분에서 크게 정리할 게 없자 오히려 뭔가 붕 뜨는 느낌을 받았다.
개념을 파다가 자연스레 익숙해져서 설정도 뚝딱할 수 있게 돼야 하는데 익숙해질 시간이 없었다.
근데 마침 이 실습 사이트로 간단하게 설정을 해보는 게 큰 도움이 됐다.
근데 깊이가 너무 얕다고도 느껴져서, 역시 엔보이 공식 문서의 실습을 해볼까도 생각이 든다.
관련 문서
이름 | noteType | created |
---|---|---|
Envoy | knowledge | 2025-04-07 |
Istio EnvoyFilter | knowledge | 2025-04-21 |
6W - 이스티오 설정 트러블슈팅 | published | 2025-05-18 |
8W - 가상머신 통합하기 | published | 2025-06-01 |
8W - 엔보이와 iptables 뜯어먹기 | published | 2025-06-01 |
7W - 엔보이 필터를 통한 기능 확장 | published | 2025-06-09 |
엔보이에 와즘 플러그인 적용해보기 | topic | 2025-06-09 |
E-이스티오의 데이터 플레인 트래픽 세팅 원리 | topic/explain | 2025-05-27 |
E-이스티오 가상머신 통합 | topic/explain | 2025-06-01 |
E-이스티오에서 엔보이 기능 확장하기 | topic/explain | 2025-06-01 |
T-엔보이 실습 with solo.io | topic/temp | 2025-04-14 |